In communication networks, network traffic may be classified and the handling of the network traffic differentiated according to the traffic class. For example, a forwarding treatment of data packets, i.e., the way of forwarding a data packet on the way towards its destination, may be controlled to provide a certain Quality of Service (QoS) level which depends on the traffic class. In other examples, the handling of the network traffic may also be differentiated with respect to charging, i.e., one traffic class could be charged in a different manner than another. Typically, traffic classification rules are defined so as to implement the differentiation between different classes of network traffic.
For example, in mobile communication networks it is known to direct network traffic related to a specific service to a bearer offering a certain QoS level. In this respect, a bearer is considered to be an information transmission context or path of defined characteristics, e.g. capacity, delay and/or bit error rate. Typically, a number of bearers will be established between a gateway of a mobile communication network and a user equipment (UE), e.g., a mobile phone or other type of mobile terminal. A bearer may carry downlink (DL) data traffic in a direction from the network to the UE, and may carry data traffic in an uplink (UL) direction from the UE to the network. In the gateway and in the UE the data traffic, which includes a plurality of IP data packets (IP: “Internet Protocol”, which may be the IP Version 4, also referred to as IPv4, or the IP Version 6, also referred to as IPv6) can be filtered, e.g., using IP 5-tuple packet filters, thereby directing the IP data packets to a desired bearer. According to the 3GPP (Third Generation Partnership Project) Technical Specifications (TSs) 23.060 V12.0.0 (2013-03) and 24.301 V12.0.0 (2013-03), a set of packet filters used to direct the data traffic to a certain bearer is also referred to as a Traffic Flow Template (TFT). In this context, a TFT can be considered as an example of a packet classification rule operating on the basis of one or more network addresses included in the data packets.
Differentiated handling of network traffic may also be useful in other types of communication network environment, e.g., using fixed access technology such as DSL (Digital Subscriber Line), fibre optical access, or coaxial cable access.
For simplifying traffic classification rules operating on the basis of one or more network addresses in a data packet, such as TFTs, it is known to perform network address translation (NAT) on data packets of the network traffic. For example, in WO 2012/052065 A1 a solution is described according to which the NAT may be used to adapt the network addresses of the data packets in such a way that data packets belonging to the same traffic class or to a similar traffic class carry network address identifiers from the same subnet. The traffic classification rule may then for example use wildcarding to detect the data packets, which allows for a simple structure of the traffic classification rule. The NAT may be used for simplifying the structure of traffic classification rules both for the DL direction from the network to the UE and for the UL direction from the UE to the network. In WO 2012/052065 A1 also scenarios are addressed which may occur when using certain protocols requiring a connection handshake at the beginning of a session, such as for example defined in RFC 793 for the Transmission Control Protocol (TCP). The TCP connection handshake involves that a node initiating a TCP session with another node sends a connection setup request in the form of a data packet including a synchronization (SYN) flag to the other node, and that the other node responds with a setup accept message in the form of a data packet including a synchronization acknowledgement (SYN-ACK) flag.
When using the NAT to assist in the traffic classification, changes in the network address of a node should be avoided while the node is engaged in a TCP session. In particular, if the node initially sends the SYN packet to a given IP address and port and receives the SYN-ACK packet from this IP address and port, the TCP implementation at the node will typically also assume that the subsequent data packets of this session should be communicated with this IP address and port. If the NAT changes the IP address and/or port during the ongoing TCP session, this most likely results in failure of further communication in this TCP session. Accordingly, WO 2012/052065 A1 provides a solution in which already the first data packet of a session initiated by the UE, i.e., the first UL data packet transmitted from the UE to a server, is sent with a certain replacement network address matching a traffic classification rule. The NAT translates this replacement network address into an external network address which is suitable for routing the data packet to the server. For providing the replacement network address to the UE, Domain Name System (DNS) messages transmitted to or from the UE when preparing the session are inspected and modified. In particular, a traffic adaptation device may inspect a DNS query sent by the UE to obtain the network address of the server and detect that the traffic with this server should be classified in a certain way. Subsequently, the traffic adaptation device may intercept a response to this DNS query and modify the response by inserting the replacement network address in place of the network address of the server. The UE then uses the replacement network address to indicate the destination of the first UL data packet to the server.
However, the above solution of WO 2012/052065 A1 may require significant resources for inspecting and processing the data traffic of the UE.
Accordingly, there is a need for alternative techniques which may be used for efficiently providing a UE with a replacement network address to be used for NAT assisted traffic classification.